Skip to content

feat(accounts-controller): add support for Snap keyring v2#8513

Open
ccharly wants to merge 8 commits intomainfrom
cc/feat/accounts-controller-snap-keyring-v2
Open

feat(accounts-controller): add support for Snap keyring v2#8513
ccharly wants to merge 8 commits intomainfrom
cc/feat/accounts-controller-snap-keyring-v2

Conversation

@ccharly
Copy link
Copy Markdown
Contributor

@ccharly ccharly commented Apr 17, 2026

Explanation

Adding support for Snap keyring v2 for this controller. For now, those keyrings are not in use, but we will need this to be able to the accounts associated with those new keyrings.

References

N/A

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed
  • I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

Note

Medium Risk
Adds new account ingestion path for SnapKeyring v2 during keyring state sync and updateAccounts, which could affect which accounts are created/removed if keyring types or lookup behavior differ. Changes are covered by new tests for v2 add/skip edge cases, keeping overall risk moderate.

Overview
Adds support for SnapKeyring v2 accounts so AccountsController can materialize Snap v2 keyring addresses into internal accounts by iterating v2 keyring instances and using lookupByAddress, injecting backward-compatible snap metadata.

Updates keyring-type utilities to recognize KeyringType.Snap (v2) as a Snap keyring (naming and filtering), and extends tests to cover v2 add/update flows and edge cases (missing keyring instance, account deleted before lookup). Also updates the messenger CLI scripts to use the oxfmt formatter and records the new capability in the changelog.

Reviewed by Cursor Bugbot for commit 3caea20. Bugbot is set up for automated code reviews on this repo. Configure here.

@ccharly ccharly force-pushed the cc/feat/accounts-controller-snap-keyring-v2 branch from 2851f32 to 235c68e Compare April 17, 2026 16:37
Comment on lines -890 to -909
const generatePatch = (): StatePatch => {
return {
previous: {},
added: [],
updated: [],
removed: [],
};
};
const patches = {
snap: generatePatch(),
normal: generatePatch(),
};

// Gets the patch object based on the keyring type (since Snap accounts and other accounts
// are handled differently).
const patchOf = (type: string): StatePatch => {
if (isSnapKeyringType(type)) {
return patches.snap;
}
return patches.normal;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just removed all this since we don't need that separation at all!

Comment on lines +877 to +889
metadata: {
name: '',
importTime: Date.now(),
lastSelected: 0,
keyring: {
type: KeyringType.Snap,
},
snap: {
name: keyring.snapId,
enabled: true,
id: keyring.snapId,
},
},
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new Snap keyring v2 only use KeyringAccount, thus we don't have any metadata for those!

@ccharly ccharly marked this pull request as ready for review April 17, 2026 17:41
@ccharly ccharly requested review from a team as code owners April 17, 2026 17:41
Comment on lines +882 to +886
snap: {
name: keyring.snapId,
enabled: true,
id: keyring.snapId,
},
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could query this from the SnapController, but that requires a new allowed action, thus a breaking change (but at least that would mimic what the current big SnapKeyring is doing)

Comment thread packages/accounts-controller/src/utils.ts
Copy link
Copy Markdown

@cursor cursor Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit c9d2191. Configure here.

...account,
// We still have to use internal account for now, so we inject some metadata.
metadata: {
name: '',
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Snap v2 accounts permanently stuck with empty name

Medium Severity

#getAccountFromSnapKeyringV2 hardcodes metadata.name to ''. When the stateChange handler creates a v2 account, this empty name gets persisted. Later, updateAccounts attempts to assign a default name using existingAccount?.metadata.name ?? 'Snap Account X', but the nullish coalescing operator (??) does not treat empty strings as nullish, so '' ?? 'Snap Account 1' evaluates to ''. The account name can never be corrected to a proper default.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit c9d2191. Configure here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine, we're in te process of deprecating account names on those objects anyway.

@ccharly ccharly enabled auto-merge April 23, 2026 20:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant